Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES
am 21.05.2009 21:25:29 von Jeff Trawick--000e0cd2458e5cff87046a711b60
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr.
> Jeff Trawick wrote:
> > Does somebody else care to share their opinion on this? Which of these
> > are okay?
> >
> > - existing mod_perl releases (and potentially other third-party modules)
> > won't compile with 2.2.12
>
> CORE_PRIVATE may be broken from release to release, it's a necessary
> concession to prevent utter stagnation :(
The bits are not CORE_PRIVATE.
You can find sample Perl code on the web that even tests these bits, though
it isn't clear to me if that is a normal practice when using the
Perl/mod_include interface.
>
>
> I believe it was a mistake that this particular symbol/this particular
> directive is not a part of the mod_includes internals :(
Perhaps, though mod_include does have a plug-in interface and we have this
non-internal-detail-sounding function called ap_allow_options(). The
include option variants could be interesting to such a plug-in.
>
>
> So given we have a .23 mmn bump, perhaps document this in that section.
> But the actual behavior of this flag changes significantly and I can't
> see how to properly maintain mod_perl, deep internal compatibility.
>
>
The requirement is to fix combinations of option specifications in the main
conf file and .htaccess. There's nothing incompatible with mod_perl there.
We just can't change the meaning of existing bits.
--000e0cd2458e5cff87046a711b60
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
A. Rowe, Jr. <=
wrowe@rowe-clan.net> wrote:
te" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt=
0.8ex; padding-left: 1ex;">
> Does somebody else care to share their opinion on this? =A0Which of th=
ese
> are okay?
>
> - existing mod_perl releases (and potentially other third-party module=
s)
> won't compile with 2.2.12
ary
concession to prevent utter stagnation :(
The bits are=
not CORE_PRIVATE.
You can find sample Perl code on the web that eve=
n tests these bits, though it isn't clear to me if that is a normal pra=
ctice when using the Perl/mod_include interface.
I believe it was a mistake that this particular symbol/this particular
directive is not a part of the mod_includes internals :(
br>Perhaps, though mod_include does have a plug-in interface and we have th=
is non-internal-detail-sounding function called ap_allow_options().=A0 The =
include option variants could be interesting to such a plug-in.
=A0
So given we have a .23 mmn bump, perhaps document this in that section.
But the actual behavior of this flag changes significantly and I can't<=
br>
see how to properly maintain mod_perl, deep internal compatibility.
The requirement is to fix combinations of option spe=
cifications in the main conf file and .htaccess.=A0 There's nothing inc=
ompatible with mod_perl there.=A0 We just can't change the meaning of e=
xisting bits.
--000e0cd2458e5cff87046a711b60--